1. Field of the Invention
The present invention relates to interfacing between an application program and a device driver in a computing system. More particularly, the invention relates to adapting an application program to communicate, without source code modification, with a device driver in a different operating system environment.
2. Description of Prion Art
Device drivers control devices in a computer operating system. Many contemporary computer architectures utilize levels or rings which are associated with access privileges relative to the operating system of the computer. At the lowest level, device drivers have unique relationships with the operating system in that they can typically have unrestricted access to all devices of the operating system, can freely examine data structures of the operating system, and can access memory locations. Furthermore, device drivers can also trap or intercept software and hardware interrupts which are detected by the operating system. Device drivers are typically maintained separately outside of application software so that the device drivers can be shared by different application programs which need to interface with devices of the operating system.
Application programs are generally one level removed from the device drivers. In order to utilize the function performed by the device driver, the application program typically makes calls to the device driver by passing parameters to and from the device driver through a software interface. In this manner, an application program can be written without the need of repeating the code contained in the device driver.
For example, the architecture employed by Microsoft's Windows.sup.1 utilizes different levels for device drivers and application programs. FIG. 1 shows levels 20 and 22, respectively known as Ring 0 and Ring 3, in a Windows architecture. The virtual device driver 24, commonly referred to as a V.times.D, is a driver in the operating system in a Windows environment. Since the V.times.D communicates with the operating system and associated computer hardware (i.e., a microprocessor capable of 32 bit operations), the V.times.D is a 32 bit program. Application program 26, such as a graphical user interface (GUI), exists in Ring 3 of the Windows architecture. Because application program 26 exists at a different level than the device driver 24, there must be some means for communications between the application program and the device driver so that the application program can utilize the
 FNT .sup.1 Windows, Windows 3.1, Windows 3.11, Windows 3.X, and Windows 95 are trademarks of Microsoft Corporation. operating system functions performed by the device driver.
As shown in FIG. 2A, in Windows 3.1 and 3.11, collectively known as Windows 3.X, application program 28 communicates with the V.times.D device driver 32 through the interface 30, provided by software interface INT 2F. Windows 3.X generally supports 16 bit applications through the interface 30 to the V.times.D. In Windows 95, a new interface between application programs and device drivers has been developed by Microsoft. As shown in FIG. 2B, the interface 38, known as DeviceIOControl(), supports 32 bit application program 36 communicating with the V.times.D device driver 40.
As interfaces between application programs and device drivers, INT 2F and DeviceIOControl() operate differently. For instance, INT 2F is a software interrupt which utilizes the AX and BX registers of the operating system. When an application program seeks to communicate with a V.times.D of Windows 3.X, the application program must manipulate the AX and BX registers appropriately and then generate the software interrupt to pass the values stored in the AX and BX registers to the V.times.D driver. Inherently, the INT 2F interface requires that the application program utilize assembly language in its calls to the V.times.D.
In contrast, the DeviceIOControl() interface of Windows 95 is a high level callable function which has a variety of arguments associated with it. Because DeviceIoControl() is a callable function, a Windows 95 application program can communicate with the V.times.D without having to utilize assembly level software interrupts or manipulate registers of the operating system.
Since application programs are written to interact with the respective interface to the device driver, the interchangeability of these application programs between Windows 3.X and Windows 95 can be problematic. While Windows 95 supports applications written using the INT 2F interface of Windows 3.X, as shown in FIG. 2B, there presently is no interface between an application written for Windows 95 using the DeviceIOControl() interface to gracefully operate in a Windows 3.X environment. In other words, Windows 3.X only supports application programs which are written to use the INT 2F interface. An application program written for Windows 95 would not operate under Windows 3.X if the application program made calls to DeviceIOControl(). Hence, software developers writing programs for Windows 95 would have to substantially modify their programs to operate under a Windows 3.X environment. This incompatibility between the interfaces to the V.times.Ds of Windows 95 and Windows 3.X results in inefficient production of software.